TODO
- 검색 없이 git, github를 할 수 있을 정도로 공부하기
고민거리와 자료들
해결 전
해결 중
해결 완료
- getter 대신 객체에게 메시지를 보내자
- toList() vs collect(Collectors.toList())
- toList() : UnModifiableList 또는 UnmodifiableRandomAccessList 반환
- collect(Collectors.toList()) : ArrayList 반환
- 순서에 맞게 정렬해서 출력을 해야하면, "정렬"은 view에서 하는 게 맞는가? 아니면 미리 해서 view에게 넘겨줘야하는가?
- 설계에 따라 다르다
- 요구사항에 따라 다르지만 우선 view 역할이라고 생각함
모든 원시값을 포장한다를 어느 수준까지 지켜야할까?
- 저 말의 의미는, 역할이 있는 원시값이면 포장해야한다라고 생각함. 역할이 없고, 이 인스턴스 변수를 갖는 클래스의 하나의 역할로써 존재한다면 굳이 포장할 필요는 없다고 생각함.
- TDD는 바텀업?
- 바텀업으로 구현을 하되, 뭐부터 해야할지 막히는 시점에서는 탑다운을 해도 좋다!
- 미리 작성한 메소드들 어떻게 다 기억하나?
- 며칠 전에 만들어둔 메소드가 있는데, 난 다른 이름의 동일 기능을 하고 있는 메소드를 짜고 있음
- 코드 베이스를 그때그때 확인해라..
- mvc패턴에서 validation의 책임은 누구에게? 참고 자료
- 우선, model에서는 model에 관련된 validation만!
- ex) Lotto에서는 로또번호의 개수 및 중복체크만, LottoNumber는 범위체크
- 나머지 validation, 예를 들어 문자열, 정수와 같은 형식이나 null 및 공백과 같은 체크는 Controller!
- 서비스의 흐름을 제어하는 주체는 Controller라고 생각함.
- 대신 Controller의 로직이 너무 복잡해지고 길어지면 View에 validation 책임을 넘겨줘도 된다고 생각함
- 테스트코드 커버리지를 100%을 달성하면서 도메인을 다 구현했는데 컨트롤러를 구현하면서 더 필요한 메소드들이 생기고, 결국 커버리지가 다시 낮아짐.
- 모든 메소드들을 고려면서 tdd를 하는 건 불가능. 커버리지가 낮아지는 게 맞다고 생각함.
- 이후에 다시 커버리지를 올리는 것을 목표로
- 필요할 것 같아서 만들어둔 메소드들이 컨트롤러에서 기능들을 합치면서 안필요해짐. 그럼 테스트 코드를 위한 코드가 되는게 아닌가?
- 사용안되는 코드가 되어버리면 삭제해야함.
- 프로덕션 코드에 테스트만을 위한 코드가 있으면 안된다고 생각함.